home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / BRIGHT~1.ZIP / Bright Blue.txt
Text File  |  1997-03-23  |  53KB  |  1,096 lines

  1.  
  2.  
  3.  
  4.  
  5.                     NCSC -TG-002<DJ0>
  6.                      Library No. S-228,538
  7.                     Version 1
  8.  
  9. FOREWORD
  10.  
  11. The National Computer Security Center has established an aggressive program to
  12. study and implement computer security technology, and to encourage the
  13. widespread availability of trusted computer products for use by any
  14. organization desiring better protection of their important data. The Trusted
  15. Product Evaluation Program focuses on the security evaluation of commercially
  16. produced and supported computer systems by evaluating the technical protection
  17. capabilities against the established criteria presented in the Trusted
  18. Computer System Evaluation Criteria. This program, and the open and
  19. cooperative business relationship being forged with the computer and
  20. telecommunications industries, will result in the fulfillment of our country's
  21. computer security requirements.  We are resolved to meet the challenge of
  22. identifying trusted computer products suitable for use in processing sensitive
  23. information.  A key service of the National Computer Security Center to the
  24. computer security community is to act as a clearinghouse for computer security
  25. issues and to develop technical security guidelines for automatic data
  26. processing systems and networks.  This technical information exchange provides
  27. guidance and interpretations for the security evaluation process and offers
  28. the vendors a central point for technical exchange.
  29.  
  30.  
  31. PATRICK R.  GALLAGHER, JR.                  1 March 1988
  32. DIRECTOR
  33. NATIONAL COMPUTER SECURITY CENTER 
  34.  
  35.  
  36.                  PREFACE
  37.  
  38.  
  39. This publication describes procedures for interacting with the National
  40. Security Agency's Information Security Organization as related to the Trusted
  41. Product Evaluation Program within the National Computer Security Center. It
  42. provides the information needed to submit a computer product for technical
  43. security evaluation and outlines the National Security Agency's
  44. responsibilities for positive, timely acknowledgements. This publication
  45. specifically covers the National Computer Security Center's relationship with
  46. vendors of proposed trusted computer products from the initial contact with
  47. the vendor through the completion of the security evaluation process and
  48. follow-on programs.  Although more detailed instructions will be referenced in
  49. this publication, sufficient guidelines are established for any first-time
  50. user of the National Computer Security Center's services.  The Office of
  51. Industrial Relations invites your comments on this document and on the
  52. National Computer Security Center's procedures for conducting security
  53. evaluations of computer products.  In cooperation with the computer industry,
  54. we can improve our national security through the availability of trusted
  55. computer products.  
  56.  
  57.                INTRODUCTION
  58.  
  59. In January 1981 the Director of the National Security Agency was assigned the
  60. responsibility for computer security for the Department of Defense.  This
  61. action led to the formation of the Computer Security Center at the National
  62. Security Agency. The Computer Security Center's Charter, promulgated in
  63. Department of Defense Directive 5215.1 in October 1982, specifically tasks the
  64. Computer Security Center to establish and maintain "...  technical standards
  65. and criteria for the security evaluation of trusted computer systems that can
  66. be incorporated readily into the Department of Defense component life-cycle
  67. management process..." The developmental experiments in the 1970's ranged from
  68. attempts to add security front-ends to existing systems to designing secure
  69. systems and hardware from scratch.  Early research and development efforts
  70. defined a graduated scale of security features and design principles. These
  71. features and principles were incorporated in the Department of Defense Trusted
  72. Computer System Evaluation Criteria (Orange Book).  The Orange Book was issued
  73. in August 1983.  In December 1985, the Orange Book was reissued as a
  74. Department of Defense Standard (DOD 5200.28-STD).  The National Computer
  75. Security Center (the Center) responds to a growing need for, and recognizes
  76. technical challenges involved in, providing effective protection within
  77. computer systems and networks of systems. The Center relies on an open and
  78. cooperative relationship with government, industry representatives, and the
  79. academic community to accomplish these important objectives. The government
  80. encourages industry to provide the computer security capabilities government
  81. needs. The Center sponsors critical research, and makes the results widely
  82. available to encourage their incorporation into trusted computer products and
  83. secure applications. The Center performs security evaluations of computer
  84. software and hardware products on commercially or government-produced computer
  85. systems.  A trusted computer system is defined as a system that employs
  86. sufficient hardware and software integrity measures to allow its use to
  87. simultaneously process a range of sensitive unclassified or classified (e.
  88. g., confidential through top secret) information for a diverse set of users
  89. without violating access privileges.  Levels of trust are based on the ability
  90. of the computer system to enforce access privileges to authorized users and to
  91. system protected files.  The Center evaluates the security features of trusted
  92. products against established technical standards and criteria, and maintains
  93. the Evaluated Products List.  The Evaluated Products List is a compilation of
  94. all computer products which have undergone formal security evaluations, and
  95. indicates the relative security merit of each computer product.  The criteria
  96. against which computer systems are evaluated is the Orange Book. This provides
  97. a metric for distinguishing a range of features and assurances for security
  98. controls built into automatic data processing system products.  The Orange
  99. Book establishes specific requirements that a computer system must meet in
  100. order to achieve a specific level of trustworthiness.  The levels are arranged
  101. hierarchically into four major divisions of protection, each with certain
  102. security-relevant characteristics.  These divisions are subdivided into levels
  103. of trust.  In recognition of the complex and technical nature of the issues
  104. addressed by the Orange Book, the Center has established a Technical
  105. Guidelines Program.  This program augments information provided in the Orange
  106. Book by publishing additional guidance on issues and features addressed
  107. therein.
  108.  
  109. TRUSTED PRODUCT SECURITY EVALUATION
  110.  
  111. This section provides the potential computer product vendor with an overview
  112. of the Center's Trusted Product Evaluation Program.  The process of a trusted
  113. product evaluation is illustrated in Figure One.  The Pre-Evaluation Review
  114. includes the initial contact between the vendor and the National Security
  115. Agency, the decision-making process to initiate, and the signing of a
  116. Memorandum of Understanding.  Note: subsystem products do not require a
  117. Memorandum of Understanding but are initiated with a Memorandum of Agreement.
  118. The Trusted Product Developmental Process provides the vendor the opportunity
  119. to obtain assistance from the Center during the development of a system or
  120. network product.  The formal product evaluation consists of the actual
  121. security evaluation of the vendor's computer system.  Successful completion of
  122. this process results in the vendor's computer product being placed on the
  123. Evaluated Products List.  
  124.  
  125. PRE-EVALUATION REVIEW
  126.  
  127. Five milestones in the application process must be reached before the security
  128. evaluation of a proposed computer product can begin.  
  129.      1.  Initial Contact
  130.      2.  Certificate Pertaining to Foreign Interests
  131.      3.  Proposal Package
  132.      4.  Program Decision
  133.      5.  Memorandum of Understanding (Memorandum of
  134.          Agreement for Subsystems)
  135.  
  136. INITIAL CONTACT
  137.  
  138. The National Security Agency point of contact for the Trusted Product
  139. Evaluation Program is the Office of Industrial Relations.  Interested
  140. companies are encouraged to call or write to: 
  141.  
  142.         Director, National Security Agency
  143.         Attention: Office of Industrial Relations
  144.         9800 Savage Road 
  145.         Fort George G. Meade, Maryland 20755-6000
  146.         (301) 688-6581
  147.  
  148. CERTIFICATE PERTAINING TO FOREIGN INTERESTS
  149.  
  150. Before submitting an application for the Trusted Product Evaluation Program,
  151. the Center requires that all companies submit a completed Certificate
  152. Pertaining to Foreign Interests prior to undertaking the additional effort to
  153. prepare a proposal package.  For those companies that already have a facility
  154. security clearance, a current DD Form 441s may be sent in lieu of the
  155. Certificate Pertaining to Foreign Interests.  Please submit the certificate or
  156. DD Form 441s to the Office of Industrial Relations, as listed above.
  157.  
  158.  
  159. PROPOSAL PACKAGE
  160.  
  161. After contact has been established, the vendor must prepare a proposal package
  162. in accordance with the following guidance. Four copies of the proposal package
  163. are required.  
  164.  
  165. This point cannot be over emphasized; information marked Company Proprietary
  166. is protected to the fullest extent permitted under the law, and must be marked
  167. accordingly.  The product proposal package should demonstrate corporate-level
  168. support for the product evaluation effort and consist of a company profile,
  169. market information and a written product proposal.
  170.  
  171. COMPANY PROFILE
  172.  
  173.     Potential computer security product vendors, whether requesting a
  174.     system, a network, or a subsystem evaluation, must establish a
  175.     formal working relationship with the Center. Vendors are encouraged
  176.     to submit as much detailed documentation as necessary to establish
  177.     their capability and suitability for the Trusted Product Evaluation
  178.     Program. The company profile portion of the submission shall include
  179.     at least the following information: 
  180.     
  181.     Company name and address.  
  182.     
  183.     State of incorporation and composition of ownership.  
  184.     
  185.     Principal point of contact, a technical point of contact, and a
  186.     public point of contact.  For each, include name and title, business
  187.     address, and business telephone.  Public point of contact names will
  188.     be placed on a list that can be provided to any requestor desiring
  189.     to establish a business connection with your company.  
  190.     
  191.     Product or services offered.  This could be supplemented with a
  192.     company capabilities brochure.  
  193.     
  194.     A recent annual or certified financial report.
  195.     
  196.     Number of people employed by the company, and in the case of a
  197.     system or network product, the projected size of the team which will
  198.     be developing, enhancing and/or maintaining the proposed product.
  199.  
  200.  
  201. MARKET INFORMATION
  202.  
  203. To evaluate the requirements for any proposed product, the vendor must provide
  204. sufficient detail to identify the utility in the market place.  The
  205. information below covers the minimum market information the Center requires to
  206. assess the probable need in the community.  The market information portion of
  207. the proposal package shall identify:
  208.  
  209.      Intended market by product type and level of trust, including a specific
  210.      customer base and/or firmly established requirements.
  211.  
  212.      Portion of markets intended to address.  How the specific market
  213.      projections were derived.  In cases where the product to be developed is
  214.      a retrofit to existing equipment, include the potential volumne of sales
  215.      for those existing equipments that are already fielded.
  216.  
  217.      Known or projected U.S.  Government requirements that the product will
  218.      satisfy.  Distinguish between DOD and Civil Agency.
  219.  
  220.      Known or projected commercial requirements that the product will satisfy.
  221.      
  222. WRITTEN PRODUCT PROPOSAL
  223.  
  224. A separate proposal is required for each computer product submitted for
  225. security evaluation.  These products must be of direct and obvious benefit to
  226. the information security posture of the nation, and should address the
  227. applicable requirements outlined in established criteria or interpretations.
  228. This determination will be based on the information contained in the product
  229. proposal, measured against national computer security needs and priorities.
  230.  
  231. The Center presently conducts three distinct types of product evaluations: 1)
  232. the system evaluation, 2) the network evaluation, and 3) the subsystem
  233. evaluation.  
  234.  
  235. Proposals For System Evaluations
  236.  
  237. The Center evaluates as a system that product which
  238. addresses all of the requirements of a given class of the Orange Book.
  239.  
  240. Although complete information about the proposed product may not
  241. be available at this stage of the design, the written product proposal should
  242. provide the following information:
  243.  
  244.     Technical description of the product.  
  245.     
  246.     What is the targeted class or level of trust?  
  247.     
  248.     What is the operating system for your product?  
  249.     
  250.     Is the proposed product currently in use?  If so, what is the
  251.     current installed base?
  252.     
  253.     What is the projected installed base over the nextve years?  
  254.     
  255.     What is the target development schedule?  How flexible is this
  256.     schedule and by what date do you plan to bring this product to
  257.     market?  
  258.     
  259.     What are the known or projected requirements that the product will
  260.     satisfy?  (Distinguish between the Department of Defense and Civil
  261.     Agencies.)
  262.     
  263.     What are the differences between and advantages of the proposed
  264.     product relative to similar products which are currently available?
  265.     
  266.     
  267. Proposals For Network Evaluations
  268.  
  269.           The Center defines a network as everything that is needed to
  270.           accomplish a job, end user to end user.  The Center defines a
  271.           network component as any part of a network.  
  272.           
  273.           The Trusted Network Interpretation of The Trusted Computer System
  274.           Evaluation Criteria (TNI) is currently the criteria against which
  275.           networks are evaluated.
  276.           
  277.           Written product proposals should provide the following information:
  278.           
  279.            A technical description of the product.  
  280.            
  281.            What is the underlying security policy of the product?  
  282.            
  283.            What level of protection is provided by the product?  
  284.            
  285.            What is the projected schedule for development?
  286.  
  287.            What are the environments for which the product is intended?
  288.            Include an overall description of the product.  Compare it to
  289.            another product currently available if possible.  
  290.            
  291.            Does your product interact with users directly?  If so, does it
  292.            provide all of the functionality identified at one of the criteria
  293.            levels in Part I of the TNI, or only a subset?  
  294.            
  295.            If it is a network system, what level of trust does it meet
  296.            according to Part I of the TNI?  
  297.            
  298.            If it is a network component, which of the following
  299.            functionalities does it provide, and at which level of trust is
  300.            each functionality provided?  
  301.            
  302.            Mandatory Access Control 
  303.            
  304.            Discretionary Access Control
  305.            
  306.            Identification and Authenication
  307.            
  308.            What other security services mentioned in Part II of the TNI does
  309.            your product provide?  
  310.            
  311.            What type of carrier medium, if any, is used or supported
  312.            by your product?  
  313.            
  314. Proposals For Subsystem Evaluations
  315.  
  316. The Center defines a computer security subsystem as a physical device or
  317. software mechanism which is added to a computer system to enhance the computer
  318. security functionality of the overall system.  
  319.  
  320. To be considered for a subsystem evaluation, a company must have an existing
  321. product which is designed to provide one or more of the following
  322. capabilities, as described in the Trusted Computer System Evaluation Criteria:
  323.  
  324.     1) mandatory access control;
  325.     
  326.     2) audit; 
  327.     
  328.     3) discretionary access control;
  329.     
  330.     4) identification and authentication; or.
  331.           
  332.     5) object re-use. 
  333.  
  334. Written product proposals should provide the following information:
  335.  
  336.  
  337.     A technical description of the product.  
  338.     
  339.     Which of the five subsystem functionalities does the product
  340.     implement?
  341.     
  342.     
  343.     What is the current installed base?  What is the projected installed
  344.     base over the next five years?  
  345.     
  346.     What is the current or projected market for your product (to include
  347.     specific customer base and/or firmly established requirements, if
  348.     possible)? What portion of this market do you intend to address?
  349.     How were the specific market projections derived?  
  350.     
  351.     What are the known or projected requirements that the product will
  352.     satisfy?  (Distinguish between the Department of Defense and Civil
  353.     Agencies.) 
  354.     
  355.     What are the differences between and advantages of the proposed
  356.     product relative to similar products which are currently available?
  357.     
  358. PROGRAM DECISION 
  359.  
  360. Upon receipt of the company's proposal package, the Office of Industrial
  361. Relations will send the company written notification that the package has been
  362. received and is under consideration.  The proposal will be reviewed to
  363. determine its value while assessing the capabilities of the company, the
  364. utility of the product to the Federal Government, and the degree to which the
  365. product addresses the technical aspects of computer security.  The
  366. availability of adequate Center resources to support the evaluation program is
  367. also a prime consideration in the program decision.  The Center may need to
  368. meet with the vendor's technical experts to ensure decision making processes
  369. are based on sound technical understanding of the product.  When a decision is
  370. reached, the Office of Industrial Relations will notify the vendor in writing
  371. whether the product has been accepted for evaluation.  System and network
  372. evaluations will enter into the Trusted Product Developmental Process as
  373. described below.  Subsystem evaluations enter directly into the formal
  374. evaluation.
  375.  
  376.  
  377. MEMORANDUM OF UNDERSTANDING
  378.  
  379.  
  380. If a package for a system or network product is accepted, a Memorandum of
  381. Understanding is executed between the vendor and the National Security Agency.
  382. The purpose and function of the Memorandum of Understanding is to establish a
  383. legal relationship between the National Security Agency and the potential
  384. vendor in which: 
  385.  
  386.     The National Security Agency agrees to provide necessary and
  387.     relevant computer security information and guidance to the potential
  388.     vendor.  
  389.     
  390.     The vendor agrees to provide the National Security Agency the
  391.     information necessary to assess the security of the proposed
  392.     product.  
  393.     
  394.     The vendor agrees to follow the intent and requirements of the
  395.     procedures leading to a system, network or subsystem evaluation.
  396.     
  397.     
  398.     The National Security Agency agrees to protect vendor proprietary
  399.     information which is provided under the Memorandum of Understanding.
  400.     
  401.     Both parties agree to review the continuation and terms of the
  402.     Memorandum of Understanding periodically.
  403.  
  404. A program manager within the Requirements and Resources Division at the Center
  405. will be assigned to monitor and coordinate technical and/or administrative
  406. responses to the vendor, and a technical point of contact within the Product
  407. Evaluation Division will be identified to the vendor.  To determine the
  408. division and class at which all requirements are met by a computer system, the
  409. system must be evaluated against the Orange Book.  This security evaluation
  410. will be conducted by a Center evaluation team.
  411.  
  412.  
  413. TRUSTED PRODUCT DEVELOPMENTAL PROCESS
  414.  
  415.  
  416. The primary thrust of this phase is an in-depth examination of a
  417. vendor's design either for a new trusted product (system or network) or for
  418. security enhancements to an existing product.It is intended to ensure that the
  419. product is actually ready for evaluation with all necessary evidence available
  420. so the evaluation can be completed without delays for additional development
  421. or evidence generation.  This phase is based primarily on design documentation
  422. and information supplied by the vendor, and it involves little or no "hands
  423. on" use of the product.  
  424.  
  425. This phase results in the production of an Initial Product Assessment Report.
  426. This report documents the evaluation team's understanding of the system based
  427. on the information presented by the vendor, and assigns a candidate Orange
  428. Book class rating to the system.  The candidate rating is an estimate of the
  429. highest class for which the product has displayed some evidence for each of
  430. the requirements in the Orange Book.  
  431.  
  432. The Center's Technical Review Board provides a consistency check on the
  433. application of the Orange Book requirements, and ensures the product is ready
  434. for evaluation.  Because the Initial Product Assessment Report does not
  435. represent a complete analysis of the computer product and may contain
  436. proprietary information, distribution is restricted to the respective vendor
  437. and the Center.
  438.  
  439.  
  440. SYSTEM AND NETWORK FORMAL EVALUATIONS
  441.  
  442.  
  443. To enter this formal evaluation phase, the design of a computer system must be
  444. finalized and marketable.  In addition, the product release being evaluated
  445. must not undergo any additional development.  Once the product is accepted for
  446. evaluation, a Memorandum of Agreement is signed between the Center and the
  447. vendor, to address the formal aspects of the product receiving an Evaluated
  448. Products List rating and the accompanying responsibilities.
  449.  
  450. At the start of this phase, a Product Bulletin is released by the enter
  451. announcing the evaluation. The Product Bulletin is a brief description of the
  452. computer system undergoing security evaluation, and includes the candidate
  453. rating of the system.
  454.  
  455. The evaluation phase is a detailed analysis of the hardware and software
  456. components of a system, all system documentation, and a mapping of the
  457. security features and assurances to the Orange Book.á The analysis performed
  458. during this phase requires "hands on" testing (i.e., functional testing and,
  459. if applicable, penetration testing).
  460.  
  461. The evaluation phase leads to the Center publishing a Final Evaluation Report
  462. and an Evaluated Products List entry. The Final Evaluation Report is a summary
  463. of the security evaluation and includes the Evaluated Products List rating,
  464. which is the final class at which the product successfully met all Orange Book
  465. requirements in terms of both security features and assurances. The Final
  466. Evaluation Report and the Evaluated Products List entry are made public.  The
  467. evaluation process represents a firm commitment from the vendor, and at its
  468. completion the product will receive a rating from the Center.
  469.  
  470.  
  471. SUBSYSTEM FORMAL EVALUATIONS
  472.  
  473.  
  474. While the Center devotes much of its resources to encouraging the production
  475. and use of multipurpose trusted computer systems, there is a recognized need
  476. for guidance on, and security evaluation of, supplementary computer security
  477. products. These subsystems may not meet all of the security feature,
  478. architecture, or assurance requirements of any one security class or level of
  479. the Orange Book. To meet this need, the Center has established the subsystem
  480. evaluation process.
  481.  
  482. The goal of the Center's subsystem evaluations is to provide computer
  483. installation managers with information on subsystems that would be helpful in
  484. providing immediate computer security improvements in existing installations.
  485. Once a subsystem product is accepted for evaluation, a Memorandum of Agreement
  486. is signed between the Center and the vendor, addressing the formal aspects of
  487. the product being included in the Evaluated Products List and the accompanying
  488. responsibilities.
  489.  
  490. Subsystems are special-purpose products which can be added to existing
  491. computer systems to increase some aspect of security and have the potential of
  492. meeting automatic data processing security needs. For the most part, the scope
  493. of a subsystem evaluation is limited to consideration of the subsystem itself,
  494. and does not address or attempt to rate the overall security of the processing
  495. environment or computer system on which the subsystem may be implemented. To
  496. promote consistency in evaluations, an attempt is made to assess a subsystem's
  497. security-relevant performance in light of applicable standards and features
  498. outlined in the Orange Book. In addition, the evaluation team reviews the
  499. vendor's claims and documentation for obvious flaws which would violate the
  500. product's security features, and verifies, through functional testing, that
  501. the computer product performs as advertised. Upon completion, a summary of the
  502. Final Evaluation Report will be placed on the Evaluated Products List.
  503.  
  504. The Final Evaluation Report will not assign a specific rating to the computer
  505. product, but will provide an assessment of the product's effectiveness and
  506. usefulness in increasing computer security.  The Final Evaluation Report and
  507. the Evaluated Products List entry are made public.
  508.  
  509. EVALUATED PRODUCTS LIST 
  510.  
  511. The Evaluated Products List provides computer users, managers and security
  512. officials, an authoritative and unbiased security evaluation of a computer
  513. system's suitability for use in processing classified and sensitive
  514. information. All products on the Evaluated Products List have been evaluated
  515. against the established criteria and interpretations. A Final Evaluation
  516. Report is issued for all products.  The rating given to a system product is
  517. the highest class for which all the requirements in the Orange Book have been
  518. met.  Trusted product security evaluation results are published in formal
  519. reports available from either the Government Printing Office or the National
  520. Technical Information Service.  
  521.  
  522. The overall evaluation class ratings given in the Evaluated Products List
  523. apply only to the specific hardware/software configurations listed.  As such,
  524. the rating indicates that the product met or exceeded each of the individual
  525. requirements for the overall Evaluation Class.  Although the computer product
  526. was subjected to the detailed security testing specified in the Orange Book,
  527. it must be emphasized that such testing is not sufficient to guarantee the
  528. absence of flaws in the product.  The Evaluated Products List entry does not
  529. constitute a general or overall endorsement of the product by the government,
  530. nor does it constitute a Department of Defense certification or accreditation
  531. of the trusted computer product for use in classified or sensitive
  532. unclassified processing environments.  Rather, the security evaluation
  533. provides an essential part of the technical evidence required for follow on
  534. certification and accreditation.  Ultimate responsibility for the continuing
  535. integrity provided by the security mechanisms of any trusted computer product
  536. evaluated by the Center rests solely with the vendor. The Evaluated Products
  537. List, which documents evaluated computer products, is available to vendors to
  538. actively market and advertise the overall evaluation class rating achieved by
  539. their products to procurement authorities and the general public.  
  540.  
  541. The Evaluated Products List contains entries for general-purpose operating
  542. systems, add-on packages, and subsystems. Product Bulletins, which are
  543. synopses of computer systems currently undergoing formal security evaluations
  544. by the Center, are also included on the Evaluated Products List.  
  545.  
  546. A hard copy of the Evaluated Products List is included in the Information
  547. Systems Security Products and Services Catalogue.  This catalogue is updated
  548. quarterly and is available through the Government Printing Office.
  549.  
  550.  
  551.  
  552. RATINGS MAINTENANCE PHASE 
  553.  
  554. The Ratings Maintenance Phase provides a mechanism to ensure the validity of a
  555. previous rating for a new version of an evaluated computer system product.  As
  556. enhancements are made to the computer product the Ratings Maintenance Phase
  557. ensures that the level of trust is not degraded. A complete re-evaluation is
  558. required to achieve a higher rating.  
  559.  
  560. The Ratings Maintenance Phase is designed to keep the Evaluated Products List
  561. current.  This is accomplished by using the personnel involved in the
  562. maintenance of the product to manage the change process and reduce the effort
  563. required to extend the rating.
  564.  
  565. Success of the Ratings Maintenance Phase depends upon the development of a
  566. cadre of vendor personnel with a strong technical knowledge of computer
  567. security and of their computer product.  These trained personnel will oversee
  568. the vendor's computer product modification process.  They will certify to the
  569. Center that any modifications or enhancements applied to the product will
  570. preserve the security mechanisms and maintan the assurances.
  571.  
  572. The Ratings Maintenance Phase is initially designed for C1 - B1 level of trust
  573. systems.  As experience is gained in the program, the intent is to extend to
  574. higher level systems and to networks.
  575.  
  576.  
  577.  
  578. EVALUATION SUPPORT SERVICES
  579.  
  580. The Center supports the trusted product security evaluation process within the
  581. Trusted Product Evaluation Program.  The following specialized technical
  582. services are available to benefit the interactive relationship between the
  583. computer product vendors and the technical staff of the Center. To obtain
  584. these services or to gain more insight into their particular detail, refer to
  585. the Points of Contact section.
  586.  
  587. DOCKMASTER
  588.  
  589.      
  590.      DOCKMASTER is an unclassified computer system used by the Center for the
  591.      nationwide dissemination and exchange of computer security information.
  592.      DOCKMASTER serves the entire information security community including the
  593.      Federal Government, universities, and private industry. It can distribute
  594.      electronic mail via connections to the ARPANET.  DOCKMASTER is accessible
  595.      by direct dial, the MILNET, and McDonnell Douglas Tymnet network.
  596.  
  597.      DOCKMASTER is the primary means of communications between the vendor and
  598.      the Center throughout the computer product security evaluation process.
  599.      It allows vendors to use electronic mail, file transfer protocols, and
  600.      the Forum subsystem.  Forum is an on-line, interactive meeting facility
  601.      that permits an individual to "meet" with other users through the use of
  602.      a computer terminal.
  603.  
  604. VERIFICATION TOOLS
  605.      
  606.      
  607.      Vendors who are developing systems that are targeted to meet the
  608.      class A1 requirements of the Orange Book must provide assurance that the
  609.      system implementation is consistent with the system's design.  This
  610.      assurance is gained by developing a Formal Top Level Specification of the
  611.      design and verifying that the specifications are consistent with the
  612.      formal security policy model (the security requirements) for the system.
  613.      After the design verification has been completed, an informal mapping is
  614.      performed from the Formal Top Level Specification to the implementation.
  615.      This completes the evidence.  Formal Top Level Specification development
  616.      and subsequent verification is a rigorous, mathematical process that can
  617.      be greatly aided by the use of automated verification tools.  The Orange
  618.      Book requires the use of such a tool in the verification of A1 systems:
  619.      "This verification evidence shall be consistent with that provided within
  620.      the state-of-the-art of the particular Center endorsed formal
  621.      specification and verification system used."
  622.      
  623.      The Center endorsed verification tools are maintained on the
  624.      Endorsed Tools List.  Examples of these verification tools are Formal
  625.      Development Methodology, Gypsy, and Enhanced Hierarchical Development
  626.      Methodology.  For information concerning the current entries on the
  627.      Endorsed Tools List, vendors should contact the Computer Hardware and
  628.      Software Support Division.
  629.      
  630.  
  631. TECHNICAL GUIDELINES
  632.  
  633. To complement the information contained in the Orange Book, the Center
  634. publishes technical guidelines which serve as additional guidance in
  635. interpreting the established standard.  These technical guidelines aid in the
  636. evaluation and selection of computer security products, both complete systems
  637. and subsystems.  In addition, they are used throughout the Federal Government
  638. and by Federal Government contractors as guidance for the procurement, use,
  639. and disposal of automation systems and their associated magnetic storage
  640. media.
  641.  
  642. The Technical Guidelines Program contributes to the technical literature on
  643. issues of computer security. Guidelines are written in response to
  644. demonstrated need in automated processing environments.
  645.  
  646. Participation in the development of technical guidelines is provided by the
  647. technical staff of the Center and its associated offices within the National
  648. Security Agency, by representatives of the Department of Defense and the
  649. Intelligence Community, by civil agencies of the Federal Government, by
  650. Federally Funded Research and Development Centers, by contracted analytic and
  651. technical firms, and by selected experts in the particular field of endeavor.
  652. Draft versions of proposed documents are extensively reviewed by a wide
  653. audience of interests, and comments are fielded for consideration before
  654. publication.
  655.  
  656. PUBLICATIONS
  657.  
  658. Technical guidelines that are published by the Center, and useful to a vendor
  659. in order to process a computer product through the Trusted Product Evaluation
  660. Program, will be provided in limited quantity by the INFOSEC Awareness
  661. Organization.
  662.  
  663. TRAINING
  664.                      
  665. The Center provides training on topics of major importance to vendors
  666. interested in the trusted product security evaluation process.
  667.  
  668. OTHER RELATED SERVICES  
  669.  
  670. Within the Information Security Organization, there are several separate but
  671. complementary programs which relate to the Trusted Product Evaluation Program.
  672. A brief description of each program is provided in subsequent paragraphs.  For
  673. more details, please contact the specific program office in the Points of
  674. Contact list.
  675.  
  676. Like the Trusted Product Evaluation Program, the Commercial Communications
  677. Security Endorsement Program is a business relationship which combines private
  678. sector leadership and expertise in equipment design, development and high
  679. volume production with the information security expertise of the National
  680. Security Agency. Specifically, this program is designed to encourage industry
  681. to embed United States Government proprietary cryptography into
  682. telecommunications products to meet the need to protect its classified and
  683. sensitive unclassified information. The Commercial Communications Security
  684. Endorsement Program products that are endorsed for protecting sensitive
  685. unclassified government information only are also available to the private
  686. sector. In today's computer networking environment, many products require both
  687. an encryption capability and a trusted computing base to meet user
  688. requirements. Companies whose products merge both communications and computer
  689. security disciplines are encouraged to become familiar with the requirements
  690. of the Commercial Communications Security Endorsement Program.
  691.  
  692. The Secure Data Network System Program was established in August 1986, when
  693. the National Security Agency joined in partnership with ten major
  694. telecommunications and computer companies to develop a security architecture
  695. and a user-friendly key management system using the Open Systems
  696. Interconnection model.á The ultimate goal of the Secure Data Network System
  697. Program is to provide for the development of information security products
  698. that can operate over a broad range of commercial data networks.  Once the
  699. Secure Data Network System architecture is formalized, the development of
  700. Secure Data Network System products will be carried out under the auspices of
  701. the Commercial Communications Security Endorsement Program.
  702.  
  703. The Industrial TEMPEST Program is designed to aid industry in developing and
  704. testing TEMPEST-suppressed equipment which can be offered for sale to the
  705. United States Government.  Companies developing trusted computing products
  706. should be aware that the United States Government may require that products
  707. protecting classified information be TEMPEST-suppressed.  
  708.  
  709. A company that produces computer security products may be interested in the
  710. Department of Treasury's Electronic Funds Transfer Certification Program if
  711. the primary function of its product is to provide message authentication in
  712. support of United States Government financial transactions.  The program
  713. specifically provides for testing, evaluating and certifying Message
  714. Authentication Code devices for Federal electronic funds transfer use in
  715. accordance with American National Standards Institute Standard X9.9.  In
  716. addition, elements of Federal Standard 1027 covering minimum general security
  717. requirements for implementing the Data Encryption Standard encryption
  718. algorithm are included.  Optional electronic key management is based on
  719. American National Standards Institute Standard X9.17.
  720.  
  721. Vendors who are developing trusted computer products as Independent Research
  722. and Development Projects may obtain technical assistance and technical plan
  723. evaluations by contacting the Center's Office of Computer Security Research
  724. and Development.
  725.  
  726. The Computer Security Technical Vulnerability Reporting Program, promulgated
  727. in Department of Defense Instruction 5215.2 in September 1986, provides a
  728. mechanism for reporting weaknesses or design deficiencies in hardware,
  729. firmware, or software that leave automated information systems open to
  730. potential exploitation.  Technical vulnerabilities reported in Evaluated
  731. Products List items could possibly change the overall rating of the product.
  732.  
  733.             Points of Contact
  734.  
  735. COMMERCIAL COMMUNICATIONS SECURITY ENDORSEMENT PROGRAM
  736.  
  737.         Director, National Security Agency
  738.         Attention: Office of Industrial Relations
  739.         9800 Savage Road
  740.         Fort George G.Meade, MD 20755-6000 
  741.         (301) 688-6581 
  742.         
  743. TRUSTED PRODUCT EVALUATION PROGRAM 
  744.         Director,National Security Agency
  745.         Attention: Office of Industrial Relations
  746.         9800 Savage Road
  747.         Fort George G.Meade, MD 20755-6000 
  748.         (301) 688-6581 
  749.         
  750. COMPUTER SECURITY TECHNICAL VULNERABILITY REPORTING PROGRAM
  751.         Director,National Security Agency
  752.         Attention: Vulnerability Reporting Program
  753.         9800 Savage Road 
  754.         Fort George G.  Meade, MD 20755-6000
  755.         (301) 688-6079
  756.         
  757. DEPARTMENT OF TREASURY'S ELECTRONIC FUNDS TRANSFER CERTIFICATION PROGRAM
  758.         Assistant Director, Security Programs 
  759.         Department of Treasury
  760.         15th and Pennsylvania Avenue NW 
  761.         Washington, DC 20220
  762.         (202) 566-5152
  763.         
  764. DOCKMASTER AND VERIFICATION TOOLS
  765.         National Computer Security Center 
  766.         Attention: Computer Hardware and Software Support Division
  767.         9800 Savage Road
  768.         Fort George G.  Meade, MD 20755-6000
  769.         (301) 859-4360
  770.         
  771.         
  772. INDEPENDENT RESEARCH AND DEVELOPMENT PROJECTS PROGRAM
  773.         National Computer Security Center
  774.         Attention: Office of Computer Security Research and 
  775.              Development 
  776.         9800 Savage Road
  777.         Fort George G.Meade, MD 20755-6000
  778.         (301) 859-4486
  779.         
  780. INDUSTRIAL TEMPEST PROGRAM
  781.         Ford Aerospace and Communications Corporation
  782.         Attention: Mail Stop 3 (Industrial TEMPEST Program)
  783.         7170 Standard Drive
  784.         Hanover, MD 21076
  785.         (301) 796-5254
  786.         
  787. PUBLICATIONS AND TRAINING
  788.         Superintendent of Documents
  789.         U.S.  Government Printing Office
  790.         ashington, DC 20402
  791.         (202) 783-3238 
  792.         
  793.         U.S.  Department of Commerce
  794.         National Technical Information Service
  795.         5285 Port Royal Road 
  796.         Springfield, VA 22161
  797.         (703) 487-4650
  798.         
  799. SECURE DATA NETWORK SYSTEM PROGRAM
  800.         Director, National Security Agency
  801.         Attention: Secure Data Network Systems SPO
  802.         9800 Savage Road
  803.         Fort George G.  Meade, MD 20755-6000
  804.         (301)668-7110
  805.         
  806. TECHNICAL GUIDELINES
  807.         National Computer Security Center
  808.         Attention: Technical Guidelines Division
  809.         9800 Savage Road
  810.         Fort George G.  Meade, MD 20755-6000
  811.         
  812.         
  813.  
  814.                 REFERENCES
  815.         
  816.         
  817. DoD 3204.1, Independent Research and Development, Under Secretary of Defense
  818. for Research and Engineering, 1 December 1983.
  819.  
  820.  
  821. DoD Directive 5200.28, Security Requirements for Automatic Data Processing
  822. (ADP) Systems, revised April 1978.
  823.  
  824. DoD 5200.28-STD, Department of Defense Standard, Department of Defense Trusted
  825. Computer System Evaluation Criteria, December 1985; supersedes CSC-STD-001,
  826. dated 15 August 1983.
  827.  
  828. DoD Directive 5215.1, Computer Security Evaluation Center, 25 October 1982.
  829.  
  830. DoD Instruction 5215.2, Computer Security Technical Vulnerability Reporting
  831. Program, 2 September 1986.
  832.  
  833. National Telecommunications and Information System Security Policy No.  200,
  834. National Policy on Controlled Access Protection Policy, 15 July 1987.
  835.  
  836. NCSC-TG-005 Version 1, Trusted Network Interpretation of The Trusted Computer
  837. System Evaluation Criteria, 31 July 1987.
  838.  
  839.  
  840. ATTACHMENT I
  841.  
  842. SPECIFICATIONS AND DESIGN DOCUMENTATION
  843.  
  844. When a vendor enters into a product evaluation, he must present evidence that
  845. his system and its design meets the appropriate criteria requirements.
  846. Examples of the type of evidence normally submitted to support an evaluation
  847. include the design specifications that explain the security mechanisms, the
  848. Trusted Computing Base (TCB) arguments that show how the TCB is tamperproof,
  849. always invoked and small enough to be analyzed.  Also, the model (or
  850. philosophy of protection) and how it relates to the implementation are
  851. important parts of the evidence.  The best test of evidence is that it must
  852. include all the information such that a new team that is basically unfamiliar
  853. with the product could evaluate only the evidence and reach the proper
  854. conclusion.  
  855.  
  856. In order for the evaluation team to review this evidence and determine whether
  857. the system complies with these requirements, the team must develop a
  858. conceptual understanding of how the system being evaluated operates.
  859. Generally, the evaluation team can acquire this level of understanding by
  860. reviewing the vendor's system documentation and specifications.  The following
  861. types of high level system documents are typically required by the evaluation
  862. team:
  863.  
  864.     User-Level Documentation
  865.     
  866.     Provides users an overview of the system, its functioning, and
  867.     information on user services.  
  868.     
  869.     Operational Manuals
  870.     
  871.     Contains general description,implementation and usage information
  872.     for the system.  It is intended for use by system programmers who
  873.     service the system.  
  874.     
  875.     Program Logic Manuals
  876.     
  877.     Documents the internal operation and organization of a system.  It
  878.     is intended for use by system programmers for program maintenance
  879.     and to determine the location of program malfunctions.  
  880.     
  881.     Administrative Manuals
  882.     
  883.     Documents the procedures for installing and generating the system.  
  884.     
  885.     Hardware and Software System Specifications
  886.     
  887.     Includes Hardware and Software design and implementation details of
  888.     the system major components
  889.     
  890.     
  891.               ATTACHMENT II
  892.  
  893. TEST PLANNING
  894.  
  895. The Department of Defense Trusted Computer System Evaluation Criteria (Orange
  896. Book) requires that vendors provide a document to the evaluators that
  897. describes the test plan, test procedures, and the results of the security
  898. mechanisms functional testing.  Security mechanisms are those mechanisms that
  899. are relevant to the Orange Book.  These include object reuse, labeling,
  900. discretionary access control (DAC), mandatory access control (MAC),
  901. identification and authentication, auditing, and trusted path.  A security
  902. related functional test plan should determine whether the system being
  903. evaluated has any design and implementation flaws that would permit a subject
  904. external to the Trusted Computing Base (TCB) to read, change, or delete data
  905. which he would not normally have access to under the mandatory or
  906. discretionary security policy enforced by the TCB.  [The TCB is defined by the
  907. TCSEC as "the totality of protection mechanisms within a computer system --
  908. including hardware, firmware, and software --the combination of which is
  909. responsible for enforcing a security policy"].  Security related functional
  910. tests involve all security properties of a system (i.e., all aspect of the TCB
  911. that affect or can be affected by a security mechanism).
  912.  
  913. COVERAGE OF TESTING
  914.  
  915. Although many standard testing methods are acceptable in fulfilling the Orange
  916. Book testing requirements, they are, for all but very small or simplistic
  917. systems, impractical to use due to the large amount of resources required.
  918. Some methods of testing that have in the past proven to be sufficient and were
  919. reasonable to implement are Interface and Mechanism testing.  
  920.  
  921. Interface testing refers to testing the TCB at the user interface (i.e., user
  922. callable routines).  Generally, critical boundaries of each security mechanism
  923. are determined and test cases on both sides of these boundaries are generated.
  924. The critical boundary of a security mechanism is the point at which the rule
  925. it is designed to implement is or is not invoked.  This provides more
  926. assurance that the view of the system presented to a user is correct.
  927.  
  928. Mechanism testing refers to the testing of the security mechanisms that the
  929. TCB supports (i.e., DAC , object reuse, audit, etc.).  Mechanism can consist
  930. of one or more interface, and some interfaces can be called by different
  931. mechanisms.  Mechanism testing shows that the TCB supports these mechanisms.
  932. The sufficiency of the different methods of testing are dependent on the
  933. particular class of the Orange Book the system is being evaluated against.
  934.  
  935.  
  936. TESTING A B2-A1 SYSTEM:
  937.  
  938. TCB interface testing is sufficient.  Every interface must be tested.  Since
  939. B2, B3 or A1 systems are well structured, and their Detailed Top Level
  940. Specifications (DTLS) and Formal Top Level Specifications (FTLS) provide a
  941. complete and accurate description of the TCB interface, the testing of the TCB
  942. interfaces can reasonably be expected to be very comprehensive.
  943.  
  944. TESTING A C1-B1 SYSTEM:
  945.  
  946. Mechanism testing is probably sufficient.  The structure allowed by a C1-B1
  947. architecture would most likely make interface testing impractical.  It is
  948. likely that an evaluation team may determine, through inspection of the
  949. system's test plan and its architecture, that black box testing of the
  950. interface is insufficient and requires "white box" testing of instrumental
  951. code sections.
  952.     
  953. DOCUMENTATION
  954.  
  955. Documentation of a test should be specific and briefly describe the TCB
  956. mechanism being tested.  The expected results of each test case should be set
  957. forth.  The test documentation should also contain an overview of the test
  958. methods being used, and the security properties which are and are not
  959. pertinent for each particular mechanism.  A list of all assumptions being made
  960. about the testing environment should also be included .  
  961.  
  962. The Orange Book functional testing requirements also require that both the
  963. system and the test plan be maintained using good configuration management
  964. techniques.  This allows the vendor to provide a form of Life-cycle assurances
  965. for the system.  Life-cycle assurance is a procedure for managing system
  966. design, development, and maintenance using a method of rigorous and formalized
  967. controls and standards.  It allows the vendor to reevaluate the system when
  968. changes are made to determine whether the integrity of the protection
  969. mechanism has been affected 
  970.  
  971.  
  972. ATTACHMENT III
  973.  
  974.  
  975. REQUIRED DOCUMENTATION
  976.  
  977. The Orange Book requires that a vendor produce documentation which describes
  978. the system protection mechanisms, how the system can operate using these
  979. protection mechanisms, how the system developer designed security into the
  980. system, and how these security features and system were tested.  The amount of
  981. documentation required increases with the targeted Orange Book class.  The
  982. specific requirements are listed below starting at the lower Orange Book
  983. classes and progressing through the higher classes.  In some cases, additional
  984. documentation may be required
  985.  
  986. C1 - DISCRETIONARY ACCESS CONTROL
  987.  
  988. Security Features User's Guide tells users how to use the security mechanisms
  989. of the system.  It provides the necessary information to understand and
  990. effectively use the discretionary access control mechanisms to protect
  991. information.
  992.  
  993. Trusted Facility Manual tells the system administrator how to set the system
  994. up so that it stays secure.  It should tell the administrator how to select
  995. the proper options such that the system is operated in a mode that meets the
  996. requirements of the Criteria.  If there are unsecure modes that the system can
  997. run in, the manual should clearly state their impact on the security and
  998. include warnings as appropriate.  This manual should also include any
  999. procedures the administrator should use during operations to maintain
  1000. security.  If any of the hardware/software features require administrator
  1001. actions to complete the security protection, they should be thoroughly
  1002. described.
  1003.  
  1004. Test Documentation describes results of security mechanism's functional
  1005. testing.  This documentation is used by the evaluation team to assess the
  1006. testing performed by the vendor.  This document describes those tests, how
  1007. they are run, and how to properly interpret the results.
  1008.  
  1009. Design documentation provides the rationale and supporting evidence for the
  1010. security of the design of the system.  The descriptive specifications are
  1011. included in this evidence.  It is intended to provide the sort of information
  1012. a new developer would need in order to support the system.  It should include
  1013. the manufacturer's philosophy of protection.  If the TCB consists of distinct
  1014. modules, the design documentation describes the interfaces between these
  1015. modules.
  1016.  
  1017. C2 - CONTROLLED ACCESS PROTECTION
  1018.  
  1019. Security Features User's Guide remains the same as C1.  
  1020.  
  1021. Trusted Facility Manual is the same as C1, but also requires details on how to
  1022. maintain audit data.
  1023.  
  1024. Test Documentation remains the same as C1.
  1025.  
  1026. Design Documentation is the same as C1.
  1027.  
  1028. B1 - MANDATORY PROTECTION
  1029.  
  1030. Security Features User's Guide remains the same as C2., but also describes the
  1031. additional security mechanisms required at this class (i.e., Mandatory Access
  1032. Control).
  1033.  
  1034. Trusted Facility Manual remains the same as C2, but also describes the
  1035. operator and administrator functions related to security.  This includes an
  1036. explanation of what's involved in changing the security characteristics of a
  1037. user, and a description of facility procedures, warnings, and privileges that
  1038. need to be controlled in order to operate the facility in a secure manner.
  1039.  
  1040. Test Documentation remains the same as C2.
  1041.  
  1042. Design Documentation remains the same as C2, but also describes the security
  1043. policy model (either formally, i.e., mathematically, or informally, i.e., in
  1044. English) and how the TCB implements this model.
  1045.  
  1046. B2 - STRUCTURED PROTECTION
  1047.  
  1048. Security Features User's Guide remains the same as B1, but also describes the
  1049. additional security mechanisms required by this class (i.e., Trusted Path).
  1050.  
  1051. Trusted Facility Manual remains the same as B1, but also details what
  1052. constitutes the TCB and how it can be modified.  It also describes how
  1053. separate operator and administrator functions need to be supported.
  1054.  
  1055. Test Documentation remains the same as B1, but includes the results of covert
  1056. channel tests.  Covert channels are communication paths that allow a process
  1057. to transfer information in a manner that violates the system's security
  1058. policy.
  1059.  
  1060. Design Documentation remains the same as B1, but also includes a formal
  1061. description of the model, and proof that it is sufficient for the policy.  It
  1062. will also describe how the TCB implements the reference monitor concept and
  1063. how it enforces the principle of least privilege.
  1064.  
  1065. B3 - SECURITY DOMAINS
  1066.  
  1067. Security Features User's Guide remains the same as B2, but also describes the
  1068. additional security mechanisms required at this class .
  1069.  
  1070. Trusted Facility Manual remains the same as B2, but also includes a
  1071. description on how to start up and restore the system security.  It also
  1072. describes the role of the Security Administrator.
  1073.  
  1074. Test Documentation remains the same as B2.
  1075.  
  1076. Design Documentation remains the same as B2, but also includes the
  1077. correspondence between the Detailed Top Level Specifications and the TCB.  The
  1078. TCB implementation is also shown to be informally consistent with the Detailed
  1079. Top Level Specifications.
  1080.  
  1081. A1 - VERIFIED PROTECTION
  1082.  
  1083. Security Features Users's Guide remains the same as B3.
  1084.  
  1085. Trusted Facility Manual remains the same as B3.
  1086.  
  1087. Test Documentation remains the same as B3, but also includes the results of
  1088. the mapping between the Formal Top Level Specifications and the TCB source
  1089. code.
  1090.  
  1091. Design Documentation remains the same as B3, but also includes a description
  1092. of the components that are strictly internal to the TCB.  It also includes a
  1093. Formal Top Level Specification to TCB correspondence.
  1094.  
  1095.     
  1096.